Present day computer and communication networks have grown to huge systems spanning entire countries or even the entire world. Correspondingly, such networks comprise a huge number of individual network elements like nodes, links, servers, routers, switches, base stations, etc. Such network elements—or: network entities—are geographically spread and are added, removed, or replaced in time.
For example, one part of a communication network is built and set up at one time or during one time period for serving the most populous parts of a country, and, at a later point in time, coverage for remaining parts of the country follows by setting up additional equipment. It should be clear that technology evolves and the equipment that was installed later may be of newer manufacturing as compared to the equipment installed first. For the case of communication networks though, equipment of newer manufacturing date may support a communication standard of a more recent revision than that of the first equipment. As a result, network equipment, network entities or network resources, supporting different standards or revisions thereof coexist.
As a result of this and the aforementioned complexity and vastness of modern network systems, it becomes a challenging task to manage such networks. It is not only necessary to keep track of all entities and resources installed/available, but also information has to be available for the manager on what entity/resource supports what standard(s) or revisions thereof.
The 3rd-Generation Partnership Project (3GPP), involved in standardizing modern telecommunication networks, has a working group “SA5” that has recently defined a number of technical specifications named IRPs (Integration Reference Point) of three different types: NRM (Network Resource Model) IRPs, Interface IRPs and Data Definition IRPs. Each NRM IRP defines a number of Information Object Classes (IOCs) in a technology-independent level specification called Information Service (IS), and each IOC is then mapped to a Managed Object Class (MOC) in one or more technology- and protocol-specific specifications called Solution Set (SS).
Implementations of the NRM IRPs will support access (management) over a 3GPP-standardized interface named Itf-N using one or more of the Interface IRPs, where a so-called IRP Agent allows an IRP Manager to manage network information in the form of Managed Objects (MOs; instances of MOOS). Such a managed object (MO) can be seen as a software object that encapsulates the manageable characteristics and behavior of a particular network entity or network resource.
This IRP agent (in this document normally referred to as “agent”) is equivalent to any service providing entity supporting an interface, e.g. a “server” in a “client-server” architecture, and the IRP Manager (in this document normally referred to as “manager”) is equivalent to any service consuming entity using an interface, e.g. a “client” in a “client-server” architecture.
These MOs that represent the real network resources in a mobile network that can be managed, e.g. a base station or a radio cell, can be created, configured, read and updated throughout their lifetime until they can be ultimately deleted. Each MO has a unique identification in the form of a Distinguished Name (DN) as defined in 3GPP technical specification (TS) document 32.300. Examples of NRM IRPs can be found 3GPP TS 32.622 (Generic NRM IRP IS) and 32.762 (E-UTRAN NRM IRP IS; from 3GPP Release-12 these are planned to be moved to TS 28.622 and 28.658), and for an overview of the IRP concept and structure, see TS 32.150.
Each implementation of the 3GPP NRM IRPs, as well as any object-oriented information model, will typically be in an telecommunications operations support system and will have a large containment tree of all instantiated MOs contained by the “root” instance. In the 3GPP NRM case this “root” instance can be the so-called “SubNetwork” IOC. The containment tree may well be contained by one of the MOs contained by the “root” instance (e.g. SubNetwork) or further down the containment hierarchy.
Such a containment tree is a structured way of representing the data that can be accessed through an interface, e.g. the standardized interface Itf-N in 3GPP. Containment can be understood as—amongst others—name-containment as defined in 3GPP TS 32.152, building up a structured tree-like hierarchy in arbitrary number of levels by means of the so-called “<<names>>”-relationship. This enables unique identification of each MO by means of a Distinguished Name (DN) as defined in TS 32.300, and it could equally well, in the general case, be any type of aggregation of classes, wherein the above-mentioned name-containment defined in TS 32.152 is one type of aggregation according to UML.
This tree of all instances, from the root SubNetwork instance, including all directly or indirectly contained MOs, down to all “leaves”, is referred to as the MIB (Management Information Base). See 3GPP TS 32.622 for the definition of SubNetwork IOC and other high-level and generic IOCs which are used in other domain-specific NRMs. The MIB is made up of instances of classes (in the 3GPP case these are IOCs and MOCs) defined in a number of specifications (in the 3GPP NRM IRP case these are IS and SS specifications, e.g. 32.622/626 (Generic NRM IRP), 32.742/746 (UTRAN NRM IRP), 32.762/766 (E-UTRAN NRM IRP) and 32.712/716 (Transport NRM IRP)).
As already mentioned, the network evolves, and different MOs in the network can be supporting different versions of the standard specifications. Thus the IRP Manager may want to be aware of which MO supports which version. Such scenarios have already been described in 3GPP SA5 contributions (cf. TR 32.830), produced during the ongoing SA5 study on version handling. Of specific interest are the following sections in the TR 32.830: 5.7 (Issue 1), 6.1.2.1 (Use Case 13 (NRM object instance versions)), and 7.2.3 (Solution proposal for Use Case 13)), and the second sub-bullet of section 7.2.3.
The latter is concerned with having the new “nsVersionInfo” attribute in the IOC named “Top” meaning that all instances (could be hundreds of thousands of them in a large installation) will have it. That would mean in a large installation, lots of attributes with the same value data. The reason why all instances will have the new attribute (NsVersionInfo) if placed in the Top IOC (Information Object Class) is that all other IOCs (and thus MOs) inherit from Top. Further background information can be found in the draft TR 32.830-030 (version 0.3.0).
Although one solution has been presented and agreed by SA5 to be included in the draft TR as a possible solution to the problem statement behind the above “Use Case” 13 is well described in this draft TR, a more substantial improvement is needed. In other words, a more efficient solution is needed that would not waste communication network resources, memory- and CPU resources by creating large amounts of duplicated information (attributes) in the Managed Objects.